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Preface 


This  document  presents  the  Final  Technical  Report  of  the  Global  Command  and  Control  System 
(GCCS)  Spatial  Data  Base  Module  (SDBM)  Extensions  effort  sponsored  by  Rome  Laboratory, 
Contract  No.  F30602-94-D-0007/Task  20,  in  accordance  with  CLIN  0002,  ELIN  A010.  The 
GCCS  SDBM  Extensions  project  focused  on  enhancements  to  the  design  and  implementation  of 
the  existing  SDBM,  a  geospatial  data  base  supporting  the  Mapping,  Charting,  Geodesy,  and 
Imagery  (MCG&I)  requirements  of  the  GCCS.  An  initial  baseline  was  implemented  and  delivered 
under  die  contract  entitled  Global  Command  and  Control  System  Spatial  Data  Base  Module. 

This  report  is  organized  into  five  sections  with  three  appendices.  The  introductory  section 
identifies  the  program  and  provides  a  background  of  the  effort  and  the  unique  objectives  that 
were  outlined  at  the  start  of  the  effort.  An  overview  of  the  specific  accomplishments  made 
during  the  effort  is  also  provided  in  the  introduction.  Section  2  provides  the  details  of  the 
technical  approach  used  to  achieve  the  objectives  of  the  effort.  A  complete  description  of  the 
Spatial  Data  Base  Module  is  presented  in  Section  3  that  includes  both  the  data  base 
architecture  and  the  software  components  to  utilize  it.  In  Section  4,  we  describe  the  work 
performed  under  the  effort  to  support  the  development  of  the  GCCS/JMTK  Extensions.  Section 
5  ends  the  report  with  the  results  obtained  from  the  development  of  the  SDBM  extensions  and 
the  conclusions  and  recommendations. 

lLt.  Douglas  Beridon  was  the  Rome  Laboratory/IRRP  project  engineer.  Mr.  Paul  Bell  was  the 
Sterling  Software  project  manager  who  directed  a  project  staff  that  included  Mr.  David 
Kolassa,  Mr.  Michael  McQuinn,  Ms.  Sandra  Stoltz,  Mr.  William  Reid,  Mr.  Jason  Hamshar,  and 
Mr.  Christopher  Williams.  The  Sterling  Software  SDBM  Extensions  project  team  is  grateful  for 
the  leadership  and  technical  support  provided  by  lLt.  Douglas  Beridon  and  RL/IRRP  during 
the  course  of  the  effort.  We  are  also  grateful  to  Ms.  Cheryl  Blake,  National  Imagery  and 
Mapping  Agency  (NIMA)  for  valuable  data  production  and  operational  insights  that  helped 
make  this  project  successful. 
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Section  l  Introduction 


1.1  Identification 

This  Final  Technical  Report  describes  the  activities  performed  by  Sterling  Software,  Information 
Technology  Division  under  the  Rome  Laboratory  (RL)  sponsored  program  entitled  the  Global 
Command  and  Control  System  (GCCS) /Spatial  Data  Base  Module  (SDBM)  Extensions.  The 
project  was  conducted  for  the  RL  Image  Products  Branch  (IRRP)  with  the  end  customer  being 
the  National  Imagery  and  Mapping  Agency.  This  twelve  month  effort  extended  the  currently 
existing  SDBM  capabilities  by  refining  the  SDBM  requirements  and  developing  a  revised 
Software  Requirements  Specification  (SRS);  developing  and  implementing  a  client-server 
interface  to  the  SDBM;  providing  the  capability  to  import  Interim  Terrain  Data  (ITD)— based  on 
the  Standard  Linear  Format  (SLF);  creating  a  data  segment  for  the  JMTK  as  part  of  the  DII  COE 
kernel;  providing  an  indexing  scheme  for  both  digital  terrain  elevation  data  (DTED)  and 
application  defined  data  to  precipitate  the  access  of  these  data  types;  and  updating  the  SDBM 
API  and  test  software. 

1.2  Program  Background  and  Objectives 

The  GCCS  is  the  primary  joint  command,  control,  communications,  computer  and  intelligence 
systems  for  the  United  States  Department  of  Defense  (DOD).  GCCS  variants  (system  and 
workstation  configurations  of  GCCS  compliant  software)  use  applications  developed  by  many 
formal  acquisition  programs  (e.g..  Standard  Theater  Army  Command  and  Control  System, 
Contingency  Theater  Air  Control  System  Automated  Planning  System,  and  the  Operations 
Support  System)  to  provide  an  integrated  capability  at  most  levels  of  command.  Development 
of  GCCS  is  managed  by  the  Defense  Information  Systems  Agency  (DISA).  The  GCCS  method, 
architecture,  environment,  and  core  software  are  also  used  by  components  of  the  DOD  (e.g., 
U.S.  Navy,  U.S.  Marine  Corps,  U.S.  Air  Force,  U.S.  Army,  DOD  Intelligence,  NIMA,  etc.)  for 
command  and  control  related  projects. 

Due  to  the  integration  philosophy  and  techniques  adapted  by  GCCS  projects,  DISA  and 
partner  organizations  are  able  to  now  field  more  capable  systems  cost  effectively.  By 
standardizing  the  way  the  software  is  built  and  integrated,  duplication  of  effort  is  avoided 
through  software  reuse.  Standardization  goes  beyond  the  structure  of  the  software.  Use  of 
common  software  to  achieve  certain  key  command  and  control  capabilities  not  only  provides  a 
common  interface  for  client  software,  but  ensures  that  the  user  sees  predictable  behavior  and  a 
familiar  user  interface  for  capabilities  that  are  found  at  a  variety  of  command  centers.  Training 
requirements  are  thus  reduced  and  user  proficiency  is  increased.  Interoperability  also  results 
from  ensuring  that  critical  command,  control,  and  intelligence  data  is  processed  by  the  same 
software  regardless  of  what  GCCS  variant  is  being  used. 

GCCS  is  not  a  DOD  development  program.  There  is  no  prime  contractor  for  GCCS.  Rattier 
GCCS  is  a  strategy,  technique,  and  set  of  standards  for  leveraging  the  development  efforts  of  a 
large  number  of  programs,  each  of  which  may  have  one  or  several  development  companies  and 
organizations.  All  participating  programs  benefit  from  the  work  done  by  other  organizations. 

As  a  response  to  shifting  budgetary  priorities  that  have  resulted  in  funding  reductions  for 
research  and  development  of  new  command  and  control  systems,  the  DOD  began  using  two 
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development  methods  that  significantly  differed  from  previous  practice  The  fost  was 
evolutionary  acquisition  or  development  (EA  or  ED).  A  system  developed  under  ED  does  not 
go  through  a  laborious  specification  process  before  development.  Instead,  the  system  is  bull  p 
and  fielded  in  a  series  of  increments. 

The  second  concept  involves  application  of  a  "bottom  up"  ralher  than  "top  down"  approach. 
Top  down  structured  analysis  breaks  the  large  system  into  modules.  In  bottom  up  analysis, 

software  is  integrated  up  from: 

•  a  common  operating  environment  (COE) 

•  existing  commercial  off-the-shelf  (COTS)  products 

•  government  off-the-shelf  (GOTS)  software 

•  newly  developed  software  to  satisfy  the  needs  of  the  user  community 

This  approach  to  integrating  software  requires  that  the  software  operate  in  an  environment 
flexible  and  robust  enough  to  satisfy  the  resource  requirements  of  a  diverse  set  of  computer 
programs.  It  also  requires  that  software  products  be  built  and  selected  to  conform  to  a  ngorous 
set  of  standards  ensuring  that  all  applications  will  come  together  as  one  entity. 

DISA  has  decided  to  consolidate  command  and  control  systems  under  development  into  a 
single  Td utecture,  making  use  of  a  core  set  of  software  services.  These  projects ;  develop 
application  software  that  will  follow  strict  standards  and  use  common  core  products  for  aU 
applicable1 functions.  In  tidting  tins  approach,  software  developed  by  one  organization  can  be 
incorporated  at  any  type  of  command  center  simply  by  choosing  to  include  it  m  the  mstaUed 
system.  This  approach  makes  optimal  use  of  program  resources  and  increases  the  capabilities 

available  to  the  user  communities. 

GCCS  has  a  binary  dynamic  library,  the  COE,  as  a  universal  application  foundation.  The  COE 
is  divided  into  nineteen  functional  areas,  one  of  which  is  mapping.  This  portion  is  referred  to  as 
thejotat  Mapping  Toolkit  (JMTK).  The  Joint  Services  Working 

has  been  trained  to  guide  and  facilitate  the  service  members  contributing  to  the  JMTK.  The  JSWG 
TOE  members  have  divided  the  mapping  portion  of  the  COE  into  three  primary  areas.  These 
areas  ^mT'DVisuab  2)  Analysis  (nonWisuld),  and  3)  Spatial  Data  Base.  Given  the  ambitious 
schedule  of  the  GCCS,  the  JSWG  COE  has  elected  to  tap  each  services  assets  to  provide 
functionality  to  JMTK;  Navy's  Chart  E  software  to  fulfill  the  Visual;  Armys  Topographic 
Evaluation  Module  (TEM)  for  the  Analysis;  and  the  Air  Force's  Common  Mapping  Too 
fCMTK)  for  the  Spatial  Data  Base  portion.  Software  modules  from  all  services  ffwy 
Sate  and  integrate  into  all  areas  of  the  mapping  COE  toolkit  in  due  lime.  These ^ekctions  are 
ratty  an  initial  departure  point  to  construct  a  mapping  COE  toolkit  which  wtil  allow  'tot- 
start"  functionality  for  GCCS. 

The  primary  objective  of  this  SDBM  effort  is  to  define,  design,  develop  and  test  mapping, 

current  CMTK  MC&G  software  as  the  basis  for  the  initial  functionality  of  GCCS. 

The  current  Spatial  Data  Base  as  a  component  of  the  GCCS  COE  JMTK  contains  the  Mowing 
capabilities*  import  NIMA  data  in  standard  formats  (VPF,  RPF,  DTED,  ITD),  archive  NBiA 
date  in  the  original  format  without  reformatting  any  data  (preprocessing);  and  provide  data 
access  and  retrieval  through  the  use  of  public  Application  Programmer  Lnterf ace  < [A .  ) 
functions.  The  information  contained  in  this  final  report  represents  a  summary  of  the  SDBM 
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Extensions  program  background,  objectives,  technical  approach,  and  functional  capabilities  of 
the  SDBM  Import  application,  public  APIs,  the  indexing  scheme  used  to  support  rapid  access 
of  the  DTED  and  application  defined  data,  and  SDBM  client-server  functionality  performed 
and  developed  under  this  effort. 

1.3  Summary  of  Accomplishments 

Six  major  accomplishments  were  achieved  during  the  SDBM  Extensions  contract. 

1.  The  design  of  die  SDBM  for  compliance  with  the  DII  COE. 

2.  The  public  and  private  SDBM  API  functions  were  enhanced.  The  SDBM  API  has  been 
modified  to  include  nine  public  API  functions.  In  support  of  the  public  API  functions, 
approximately  150  private  API  functions  have  also  been  developed.  The  API  functions 
were  developed  and  documented  according  to  JMTK  Working  Group  standards.  The  API 
Test  application  and  the  SDBM  Import  application  were  modified  to  access  the  enhanced 
SDBM  API  functionality. 

3.  A  Spatial  Data  Base  Server  was  developed  and  delivered  during  this  effort.  The  Spatial 
Data  Base  Server  supports  all  the  services  that  can  be  accessed  through  the  SDBM  toolkit. 
The  Spatial  Data  Server  is  different  than  the  toolkit  in  that  it  is  designed  to  specifically  run 
in  the  DII  COE,  whereas  the  SDBM  toolkit  will  not  be  aware  of  the  DII  COE  architecture. 

4.  An  indexing  capability  was  implemented  to  support  the  quick  and  efficient  access  of 
DTED  data  and  application  defined  data.  The  implementation  is  based  upon  a  balanced 
R-Tree,  where  each  node  represents  a  spatial  area. 

5.  Support  for  asynchronous  processing  implemented.  Several  of  the  services  within  the 
SDBM  are  time-consuming  in  nature,  or  require  lengthy  processing  time.  This  contract 
provided  the  capability  to  perform  a  select  set  of  SDBM  functions  asynchronously,  thus 
providing  the  capability  to  continue  processing  other  tasks  while  a  lengthy  task  is 
completing.  A  transaction  process  was  developed  for  SDBM  under  this  effort  in  order  to 
provide  the  capability  to  a  user  to  inquire  the  status  of  a  particular  asynchronous  process, 
or  to  abort  a  task  before  processing  is  complete. 

6.  A  data  retrieval  capability  was  developed  which  provides  a  retrieval  service  to  obtain 
geospatial  data  maintained  by  he  Spatial  Data  Base  Module.  RPF  data  remains  retrievable 
in  its  native  format  as  it  was  within  he  version  3.0  SDBM  software.  DTED  software  can 
be  retrieved  in  its  native  format  or  it  can  be  retrieved  in  a  tailored  format  where  he 
requester  can  specify  he  area  of  interest,  he  data  resolution,  he  origin  of  he  data,  etc. 
Application  defined  data  is  also  retrievable  through  he  enhancements  made  during  this 
effort. 

During  his  contract  the  following  deliverables  and  technical  documentation  were  delivered: 
Monthly  Status  Reports,  Software  Test  Description,  Software  Test  Plan,  Configuration 
Management  Plan,  GCCS  Spatial  Data  Base  Extensions  Software  Requirements  Specification,  a 
Software  Design  Description  Document,  SDBM  Computer  Programmer's  Manual,  SDBM 
Software  User's  Manual,  Presentation  Materials,  and  he  SDBM  Computer  Software. 
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Section  2  Program  Overview 


2.1  Refinement  of  the  Spatial  Data  Base  Requirements 

Sterling  Software  performed  a  review  and  analysis  of  the  functional  requirenneirtsdoc^navt  for 
JMTK,  dated  20  July  1995.  This  analysis  led  to  the  development  of  the  current  SDBM  Soft" 
Requirements  Specification  for  the  GCCS  Spatial  Data  Base  Extensions,  dated23  August  1996^ 
The  SDBM  Software  Requirements  Specification  Document  idenaftes  *e  JMTK  requirements 
recognized  as  belongingVo  the  Spatial  Data  Base  Domain  of  JMTK  These  requirement  were 
placSTin  a  logical  foimat  flow  within  the  SDBM  software  requirements  specification  to 
establish  the  specific  requirements  of  the  Spatial  Data  Base  Module  computer  software 
configuration  item  (CSCI)  of  the  JMTK. 

2.2  SDBM  Extensions  Design 

The  SDBM  was  designed  to  be  one  of  three  architecture  components  of  the  JMTK,  with  the  other 
two  components  consisting  of  the  Visual  Module  (displays  of  maps  and  overlays),  and  the 
Analysis  Module  (terrain  analysis,  line  of  sight,  etc.).  The  objective  of  the  SDBM  Extensions 
Design  was  to  extend  the  design  of  the  MC&G  spatial  date  tasemanagement  and  data  access 
software  of  the  Spatial  Data  Base  Module  of  the  GCCS  COE  JMTK. 

Sterling  Software  defined  the  spatial  data  base  and  data  access  requirements  for  the  GCCS 
SDBM  effort  by: 

1  Providing  assistance  and  becoming  actively  involved  with  the  JMTK  Working  Group  to 
define  the  API  for  the  Spatial  Data  Base  and  Data  Access  software. 

2  Analyzing  existing  NIMA  MCG&I  datasets  (e.g.,  CADRG,  VMAP  Level  0,  DTED,  etc)  to 
define  data  commonalty  among  the  various  mapping  products  and  providing  proposed 
solutions  to  limit  and/or  eliminate  redundant  data. 

Under  this  effort.  Sterling  Software  enhanced  the  design  of  the  GCCS  SDBM  which  was 
compliant  with  the  GCCS  COE  Data  Management,  Data  Access,  and  Data  Interchange  Semces 
(DISL  This  module  provided  full  support  for  the  access  and  data  base  management  of  MCG&I 
data  required  by  the  GCCS  JMTK  Visual  and  Analysis  modules.  This  task  was  adueved  by 

examiningand  thoroughly  understanding  the  cummt  COE  to°^orate 

extended  the  design  of  the  data  base  management  functions  for  the  GCCS  SDBM  to  incorpo 

the  following  functionality: 

.  indexing  of  the  graphical  data  types  DTED  and  JMTK  application  defined  data 

•  a  client-server  interface  to  the  Spatial  Data  Base  toolkit  of  functions 

•  retrieval  of  geospatial  data  based  upon  a  "tailored  request 

The  data  base  management  functions  designed  under  this  phase  for  the  GCCS  SDBM 
maintained  a  consistency  with  the  specifications  identified  within  the  Functional  Speaficatio 
for  the  JMTK,  as  those  specifications  pertain  to  the  task  of  data  base  managemen  or  eJMTK 
and,  therefore,  the  GCCS  SDBM.  Sterling  Software  also  designed  a  COE-compW  DIS  to 
import  and  export  MCG&I  datasets  and  associated  metadata  to  and  from  the  GCCS  SDB  . 
TheWSdesign  allowed  for  the  import  and  export  of  MCG&I  datasets  m  their  native  NIMA 
formats.  The  DIS  design  also  allowed  the  datasets  to  be  accessible  from  the  associated  storage 

media  of  each  data  type. 
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2.3  Implementation  of  the  SDBM  Extensions 

Sterling  Software  has  developed  an  initial  baseline  of  the  Spatial  Data  Base  Module.  The  initial 
implementation  indudes  the  support  of  RPF,  VPF,  DTED,  and  ITD  datasets,  and  associated 
metadata.  The  initial  implementation  performs  the  Data  Base  Management  functions,  the  Data 
Access  Functions,  and  the  Data  Interchange  Service  functions  described  in  Section  2.2  and 
relevant  to  the  support  of  the  datasets. 

All  computer  software' designed  and  developed  for  this  effort  adheres  to  Mil-Std-498,  entitled 
Software  Development  and  Documentation,  dated  5  December  1994.  Also,  all  SDBM  software 
APIs  have  been  developed  in  C.  All  software  delivered  under  this  task  is  completely 
maintainable  and  modifiable  with  no  reliance  on  any  non-delivered  computer  programs  and 
documentation.  All  software  has  been  developed  and  tested  under  the  following  platforms  and 
operating  systems: 

•  Sun  Workstation  -  Solaris  2.4,  SunOS  4.1.3 

•  Hewlett  Packard  -  HP-UX  10.10 

All  JMTK  software  components  are  compatible  with  the  following  commercial  and  public 
software  versions: 

•  X11R5 

•  OSF  Motif  1.2.2 

2.4  SDBM  Software  Testing 

The  GCCS  SDBM  software  has  undergone  rigorous  testing  throughout  the  development  cycle  of 
this  effort.  Modularized  software  has  been  tested  thoroughly  by  each  engineer  responsible  for  a 
particular  unit/portion  of  software  that  was  developed  before  it  was  integrated  into  the 
baseline  of  SDBM.  The  baseline  SDBM  was  also  thoroughly  tested  on  a  regular  basis  to  ensure 
that  incorporation  of  a  software  module  did  not  affect  the  functionality  of  the  SDBM. 

Sterling  Software  performed  extensive  tests  on  all  capabilities  of  the  GCCS  SDBM 
enhancements  to  verify  that  all  requirements  for  the  effort  were  met.  A  Software  Test 
Description  document  was  written  to  describe  the  format  of  the  test  plan,  test  descriptions,  and 
test  procedures  for  the  GCCS  SDBM  Extensions  effort.  Upon  installation  of  the  GCCS  SDBM 
Extensions  software  at  the  designated  Government  facility,  the  software  test  was  repeated  in 
accordance  with  the  Software  Test  Description  document. 

To  ensure  that  the  SDBM  API  functions  were  fully  operational,  a  software  testing  tool  was 
developed.  The  ApiTest  Tool  was  developed  to  test  each  API  function  before  it  was  integrated 
into  the  SDBM.  The  ApiTest  Tool  allowed  for  all  tests  to  be  performed  in  a  controlled 
environment  using  predesignated  steps  and  inputs,  to  produce  results  that  could  be  observed 
and  evaluated. 

The  formal  test  procedures  were  conducted  at  Sterling  Software's  facility  in  Rome,  New  York  in 
August  of  1997.  The  test  procedures  were  conducted  by  a  Sterling  Software  engineer  and 
witnessed  by  the  GCCS  SDBM  Extensions  project  engineer  from  Rome  Laboratory /IRRP, 
Lieutenant  Beridon,  and  an  additional  Government  employee  from  Rome  Laboratory.  All  tests 
were  performed  to  the  satisfaction  of  Government  attendees.  A  Software  Test  Plan  was  also 
written  and  provided  to  the  Government  in  order  to  specify  the  exact  times,  dates,  locations, 
etc.,  at  which  the  formal  test  procedures  were  conducted. 
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2.5  SDBM  Software  Integration 

The  GCCS  SDBM  software  has  undergone  multiple  integration  steps  ^oughits  ^  cycle. 
Sterling  Software  supported  all  integration  activities  m  accordance  with  the  GCCS  Integration 
Standard.  The  following  identifies  the  main  areas  of  integration  that  Ster  go  are  as 

supported: 

•  integration  of  the  MCG&I  data  server  into  the  GCCS  COE 

•  integration  of  all  SDBM  APIs  and  functional  software  into  the  GCCS  JMTK 

Sterling  Software  provided  continuous  support  in  the  above  areas  throughout  the  SDBM  task  In 
2sSg taL  integration  effort  of  the  GCCS  SDBM,  Sterling  Software  used  the  Telnet 
communication  capabilities  that  were  established  during  initial  phases  of  the  SDBMeffort 
communications  configuration  has  proven  to  be  a  highly  efficient  method  of  integration,  trouble 
shooting,  and  maintenance  support  for  this  effort. 

Also  during  this  effort  Sterling  Software  engineers  performed  on-site  integration  support  at  the 
^C  Sy^em  Wepator's  fadlity,  when  needed,  in  order  to  facilitate  the  mtegrahon  of  (he 
SDBM  software  segment  into  the  JMTK  baseline. 
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Section  3  SDBM  Extensions  Description 


The  Joint  services  have  previously  developed  and  maintained  their  own  software  products  to 
support  MCG&I  requirements.  Although  functionality  is  shared  by  the  individual  mapping 
applications,  each  implementation  is  unique.  To  provide  the  Joint  services  with  a  set  of  common 
capabilities  and  a  common  implementation,  the  GCCS  program  is  working  towards  the 
development  of  a  COE.  MCG&I  is  just  one  of  many  functional  areas  within  the  COE 
architecture  being  addressed  by  the  development  of  a  Joint  Mapping  Toolkit. 

The  JMTK  is  being  developed  as  a  collection  of  APIs  that  enable  support  applications  to 
interface  with  MCG&I  functionality.  Version  3.2  of  the  JMTK  is  comprised  of  three  distinct 
modules:  the  Visual  Module,  which  provides  map  presentation  functionality;  the  Analysis 
Module,  which  performs  geospatial  computations;  and  the  Spatial  Data  Base  Module,  which 
provides  the  geospatial  data  management  services. 

The  Spatial  Data  Base  Module  operates  in  two  modes,  interactive  and  client-server.  The 
interactive  mode  supports  all  the  user  directed  activities  required  by  the  Spatial  Data  Base 
Module  within  a  stand-alone  application.  This  includes  the  capabilities  to  import,  manage,  and 
export  the  data.  The  client-server  mode  encompasses  the  same  activities,  but  in  a  client-server 
environment  where  the  server  has  access  to  the  JMTK  and  one  or  more  clients  can  unport, 
manage,  and  export  data  to/ from  a  JMTK  environment. 

The  following  sections  of  this  Final  Technical  Report  describe  the  Spatial  Data  Base 
architecture,  the  set  of  API  functions  provided  by  version  3.2  of  JMTK,  and  the  Spatial  Data 
Import  Application  developed  to  provide  a  means  of  populating  a  spatial  data  base. 

3.1  Spatial  Data  Base  Architecture 

The  Spatial  Data  Base  Module  architecture  is  based  on  a  hierarchical  directory  structure  of 
metadata.  This  structure  effectively  remains  the  same  as  it  has  in  previous  deliveries  of  the 
SDBM  software,  with  minor  modifications  made  to  enhance  tire  metadata.  Figure  3-1  depicts 
this  Spatial  Data  Base  metadata  directory  structure.  Three  levels  of  metadata  summarize  die 
actual  standard  NIMA  data.  The  metadata  does  not  contain  any  actual  data  within  the 
structure:  it  simply  describes  the  data  and  provides  information  as  to  where  the  data  is 
physically  located  on  the  system. 

Level  1  metadata  provides  an  overview  of  the  entire  data  base.  Each  data  base  is  named  at 
creation.  The  action  of  creating  a  new  data  base  causes  a  directory  structure  to  be  built  within 
the  Spatial  Data  Base  environment.  The  directory  is  labeled  with  the  data  base  name  and  an 
initial  metadata  structure  is  placed  within  that  directory.  This  metadata  structure  is  continually 
updated  as  datasets  are  added  to  the  data  base.  A  format  directory  (i.e.,  VPF,  RPF  GRD,  SLF) 
is  added  beneath  the  data  base  directory  each  time  a  new  format  is  presented  for  import.  No 
metadata  is  associated  with  this  directory  level. 

Level  2  metadata  contains  information  describing  volume  metadata  (i.e.,  DCW,  CADRG, 
DTED,  ITD)  and  all  datasets  of  a  particular  volume.  Each  time  a  new  data  type  or  volume  of 
data  is  imported  into  the  data  base,  a  directory  is  built  beneath  the  appropriate  Format 
directory  to  indicate  the  new  data  type.  The  metadata  at  the  volume  level  and  at  the  data  base 
level  are  updated  to  reflect  the  addition  of  the  new  data. 
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Figure  3-1.  Spatial  Data  Base  Architecture 

Level  3  metadata  contains  information  describing  a  particular  dataset  which  has  been  imp0^ 

•  f  a  n^rtimlar  data  base  As  a  new  dataset  is  imported  into  a  data  base,  a  directory  structure 
is  built* beneath  the  appropriate  volume  directory  and  all  three  levels  of  metadata  are  updated 

accordingly. 

For  the  JMTK  3.2  delivery,  a  dataset  is  equivalent  to: 

a.  a  compact  disk  (CD)  distributed  by  NIMA  containing  a  standard  N1MA  product, 
such  as  VPF,  RPF,  DTED; 

b.  an  8mm  tape,  such  as  that  containing  HD  data  that  can  be  copied  to  a  disk;  or, 

c.  a  file  found  on  a  disk  (e.g.,  application  data) 

■  Prior  to  the  import  process,  the  data  in  CD  format  can  reside  on  the  CD  itself,  or  may  be ^copied 
to  hard  disk.  Future  versions  of  JMTK  will  allow  a  dataset  to  represent  a  portion  of  date  taken 
lorn  a  CD  HD  data  distributed  on  8mm  tape  must  first  be  loaded  onto  a  disk.  The  data 
referenced  by  the*  metadata  can  remain  on  CD  or  it  can  be  placed  on  hard  disk  during  the 

import  process  for  JMTK  3.2. 

The  three  levels  of  metadata  within  the  Spatial  Data  Base  architecture  will  develop  and  mature, 
SaorTinfonnatton  about  the  actual  data  as  future  releases  of  JMIK  develop  and 

mature 

3.2  Application  Programmer  Interface  (API) 

As  depicted  in  Figure  3-2,  the  API  for  JMTK  provides  a  means  of  interaction  between  common 

iid sLice  specif applications  and  a  JMTK  ^vkonm<mtJhe  D^a  Base 

the  three  distinct  modules,  the  Visual  Module,  the  Analysis  Module,  and  the  Spatial  Data  Base 
Module  The  set  of  module-related  API-level  functions  have  been  enhanced  and  extended  for 
JL2  of  these  modules  within  the  JMTK  3.2  release  to  provide  a  common  and  consistent  view  of 
thebattiefield  to  all  military  players.  Future  versions  of  JMTK  will  build  upon  this  exdianced 
baseline  to  provide  additional  functionality  in  increments,  as  the  enhancements  did  for  this 

delivery. 


Service  Specific  Application  Common  Application 

- API  = 


U 


Other  H/ICG&I  Data  NIMA  Data  Analytical  Results 


Figure  3-2.  GCCS  JMTK  3.0  Architecture 

Nine  public  API  functions  have  been  delivered  to  provide  access  to  the  Spatial  Data  Base 
Module  functionality.  Approximately  150  private  API  functions  have  been  delivered  in  support 
of  these  nine  public  APIs.  All  the  APIs  have  been  developed  and  documented  in  accordance 
with  the  JMTK  Working  Group  Standards. 

The  following  is  a  brief  description  of  the  public  APIs  provided  for  interaction  with  the  Spatial 
Data  Base  Module  of  JMTK  3.2: 


JMS_SdbInit 

Initializes  the  connection  structures  and  sets  global  values 
used  throughout  the  SDBM. 

JMS_ConnectService 

Establishes  or  terminates  a  connection  with  the  Spatial 
Data  Base  Module  and  sets  or  retrieves  connection 
preferences. 

JMS_DataStore 

Stores  MCG&I  data  or  application  data  in  a  JMTK  spatial 
data  base. 

JMS_Db  Query 

Queries  the  contents  of  spatial  data  holdings  managed  by 
the  Spatial  Data  Base  Module. 

JMS_DataRetrieve 

Retrieves  data  from  a  spatial  data  base. 

JMS_DbService 

Provides  the  capability  to  create  and  manage  JMTK  spatial 
data  bases. 

JMS_DDService 

Provides  SDBM  and  application  data  dictionary  services. 

JMS_TransactionService 

Retrieves  the  status  and  percentage  of  completion  for  a 
specified  transaction  identifier  and  cancels  specified 
transactions. 

JMS_ErrorGet 

Retrieves  the  text  message  for  the  specified  error  code. 
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3.3  Import  Application 

The  SDBM  Import  application  was  enhanced  during  this  effort.  The  application  provides  the 
JMTK  Spatial  Data  Base  Module  developers  with  a  means  of  populating  a  Spatial  Data  Base  in 
SeSntext  of  a  JMTK  environment.  It  also  provides  a  valuable  means  for  testing  theAPI-levd 
functions  required  for  the  JMTK  3.2  delivery.  SDBM  Import  users  can  use  the  aPP1^catJ0^  t° 
create  new  data  bases,  import  standard  NIMA  data  to  a  data  base,  and  perform  spatial  data 

base  management  functions. 

Several  enhancements  were  made  to  the  SDBM  Import  application  during  the  SDBM  Extensions 
contract  The  most  evident  of  the  SDBM  Import  application  modifications  are  the  enhancements 
m^de  to  exerdse  L  JMTK  3.2  SDBM  API.  Additionally,  the  presentation  screens  were 
modified  slightly  to  provide  a  more  flexible  screen  layout.  This  was  done  with  the  expectataon 
that  future  versions  of  JMTK  will  be  using  the  SDBM  Import  application  and  will  want  to  easily 
^p aru^the^  interface  io  accommodate  new  capabilities.  Currently  two  of  die  ^  screen 
nJnpk  are  implemented  and  functional  for  the  SDBM  Import  application  3.2  release.  The 
Import  Panel  provides  the  SDBM  user  with  the  capability  to  import  standard  N^  P^ucte 
into  an  SDBM  data  base.  The  Data  Management  Panel  allows  the  user  to  perform  data  bas 
management  functions  such  as  creating  and  deleting  an  SDBM  data  base,  and  copying,  moving, 
backing  up  a  data  base,  etc. 

It  is  expected  that  this  application  will  evolve  into  an  SDBM  developer's  tool  in  future  versions 
of  JMTK  The  software  provides  a  baseline  tool  which  can  be  expanded  according  y  0  a 
the^^lopment  of  additional  API-level  functions,  provide  a  resource  for  testmS  ^tiondrty, 
provide  a  resource  for  regression  testing,  and  provide  a  method  for  quickly  populating  a  Spa 
Data  Base  for  future  versions  of  JMTK. 
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Section  4  SDBM  EXTENSIONS 


4.1  Indexing  Capability 

The  SDBM  Extensions  effort  provided  the  capability  within  SDBM  to  index  both  DTED  and 
application  defined  data.  The  indexing  mechanism  is  used  to  expedite  the  retrieval  process  for 
both  of  these  data  types. 

The  indexes  are  created  and  maintained  using  an  R-Tree.  In  this  application,  the  R-Tree  is  a 
balanced  tree  data  structure  where  each  node  represents  a  spatial  area  as  a  minimum  bounding 
rectangle.  The  child  nodes  represent  the  actual  data  being  indexed  while  the  parent  node  is  a 
superset  of  its  children.  Figure  4-1  shows  the  child  nodes  of  the  spatial  areas  a,  b,  c,  and  d  and 
how  they  correspond  with  the  parent  nodes  of  the  larger  spatial  areas  AA  and  BB.  This 
implementation  will  provide  for  a  quick  and  efficient  search  of  the  spatial  data  maintained 
within  the  SDBM. 


Figure  4-1.  Parent-Child  Node  Relationships  within  an  R-Tree 


The  indexing  scheme  used  in  SDBM  initially  builds  an  index  file  for  each  data  format  as  it  is 
imported  into  an  SDBM  data  base.  A  master  index  list  of  pathnames  to  the  lowest  level  of  the 
data  maintained  within  the  SDBM  (i.e.,  frames,  files,  tiles)  is  also  created.  One  master  index  file 
will  exist  for  each  data  base.  The  data  format  index  file  and  the  master  index  list  are  used 
together  to  build  an  index  file  that  resides  in  memory  as  an  application  accessing  the  SDBM  is 
operating.  It  is  the  memory  resident  index  file  that  is  accessed  to  provide  pathnames  to  the  data 
indexed,  as  requested. 

The  indexing  mechanism  consists  of  three  functional  areas: 

1.  Construction  of  the  index  file(s)  for  a  unique  data  base  connection. 

2.  Maintenance  of  the  index  file(s). 

3.  Retrieval  of  the  pathnames  for  a  particular  subset  of  data  using  the  index  file(s). 


11 


The  construction  of  an  index  file  is  performed  when  a  connection  to  the  SDBM  is  requested  An 
index  is  built  by  first  checking  whether  any  index  files  exist  for  the  data  bases  specified  for  a 
particular  connection.  A  check  is  then  made  to  identify  whether  any  data  resides  within  those 
index  files  for  the  area  of  interest  (AOI)  specified.  The  index  built  will  reside  m  memory  for  a 
particular  connection  ID  only.  This  in-memory  index  will  be  used  by  the  data  retrieve  function. 

The  maintenance  of  the  index  files  occurs  during  the  import  process  of  SDBM.  When  data  is 
imported,  the  AOI  of  the  data  is  inserted  into  the  index  file  along  vnth  a  file  offset ^^Thif is 
index  file  which  indicates  where  the  path  to  that  segment  of  data  can  be  found.  This  is 
performed  for  each  lowest  level  representation  of  the  data  (i.ev  frame,  file,  or  file)  a  is  g 
imported.  This  delivery  of  SDBM  supports  the  indexing  of  DTED  and  application  defined 
data.  Future  releases  of  SDBM  will  support  the  indexing  of  additional  data  types. 

The  index  retrieve  function  searches  an  index  for  a  particular  connection  and  returns  five  exact 
path(s)  to  the  data  that  matches  the  criteria  provided  in  the  SDBM  retrieve  request.  The  mdex 
retrieve  function  will  search  the  in-memory  index  by  AOI.  If  the  AOI  requested  mtersects  with 
the  AOI  represented  by  the  index  file,  the  offset  in  the  master  index  file  will  be  given ^and  the 
pathname  Will  be  extracted  from  that  file.  This  pathname  will  ^n. 

retrieval  function  the  file,  or  files,  that  contain  the  actual  map  data.  The  SDBM  retoevaL 
function  wfil  use  the  pathname(s)  to  return  the  actual  requested  map  data,  or  will  use  the 
pathname  to  access  the  data  for  further  processing. 

The  indexing  algorithm  used  is  based  on  original  test  code  written  by  Torn  Guttman  and  later 
ported  to  ANSI  C  on  a  variety  of  platforms  by  Daniel  Green.  The  software  has  been  rnodi  e 
function  within  the  guidelines  of  the  SDBM  implementation  and  software  coding  standards. 

4.2  Transaction  Service  for  Asynchronous  Processing 

Several  functions  within  the  SDBM  API  perform  tasks  which  require  lengthy  processingtimes^ 
To  free  up  the  system  processor  for  other  processing,  an  asynchronous  background  taskmg 
method  was  implemented.  This  method  was  employed  as  part  of  the  SDBM  Extensions  effort 
to  SIS  system  calls  *  create  new  child  processes.  SDBM 
support  asynchronous  processing  for  the  SDBM  3.2  delivery  indude  JMS.DataStore  and 

JMS_DbService. 

A  transaction  process  was  developed  which  provides  the  opportunity  for  an  SDBM  user  to 
determine  the  status  of  an  asynchronous  task.  The  user  can  continue  with  his/her  activities 
within  an  SDBM  application  while  an  asynchronous  process  is  performing  the  requested  , 
yet  have  a  means  to  obtain  the  status  of  that  asynchronous  task  at  a  later  time.  When  an 
asynchronous  task  is  executed,  the  user  receives  a  transaction  identifier  indicating  the  task. 
TWgh  the  use  of  the  SDBM  API  function,  JMSJTransactionService,  the  user  can  mquire  five 
status  of  the  process  identified  by  the  transaction  identifier.  The  status  returned  would  indie 
the  portion  of  five  task  complete  (percentage)  or  an  error. 

4.3  Client-Server  Architecture 

The  SDBM  was  designed  and  enhanced  under  the  SDBM  Extensions  effort  to  run  both  as  a 
client-server  architecture  and  as  a  library  or  toolkit  of  functions  that  a  stand-alone  aPpbcation 
would  indude  and  exerdse  within  the  application  environment.  The  client-server  architecture 
was  built  using  remote  procedure  call  (RPC)  communications. 
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In  the  context  of  the  client-server  environment,  the  SDBM  Server  was  designed  and  built  to  use 
the  SDBM  toolkit  of  functions.  The  SDBM  Server  would  include  the  toolkit  library  exactly  as  a 
stand-alone  application  in  order  to  access  the  SDBM  API.  A  client  application  would  call  the 
same  SDBM  API.  However,  the  API  function  call  in  the  client-server  configuration  actually 
packages  up  the  parameters  passed  to  the  API  and  provides  the  package  to  the  Server  to 
unpack  and  make  the  actual  call  to  the  SDBM  API.  In  effect,  the  client  is  calling  the  SDBM  API, 
but  using  the  RPC  to  access  an  SDBM  server  to  obtain  the  results  of  an  SDBM  API  function  call. 

Both  the  toolkit  and  the  client-server  architectures  support  the  capability  to  perform 
asynchronous  processing  of  time-consuming  SDBM  tasks.  The  client  and  the  server  software 
function  on  both  the  Solaris  and  the  HP-UX  operating  systems. 

4.4  Retrieval  of  DTED  and  Application  Data 

The  SDBM  software  was  enhanced  under  the  effort  to  provide  a  capability  to  retrieve  spatial 
data  from  an  SDBM  data  base.  The  SDBM  Extensions  effort  was  able  to  achieve  this  capability 
for  the  DTED  and  application  defined  data  types.  These  data  types  are  capable  of  being 
retrieved  from  within  an  SDBM  data  base  in  either  a  native  format  or,  in  the  case  of  DTED 
data,  a  tailored  format  defined  by  the  application  as  part  of  the  retrieval  request.  The  SDBM 
software  will  be  enhanced  in  future  releases  of  SDBM  to  include  the  retrieval  of  additional  data 
types.  Future  releases  will  also  provide  the  capability  to  retrieve  the  data  types  as  a  composite 
map  image  of  the  requested  spatial  data.  This  will  return  the  data  as  a  raster  image  for  display. 

For  version  3.2  of  the  SDBM  software,  an  application  requesting  data  will  provide  a  data  type 
as  part  of  the  request.  The  data  type  parameter  is  used  to  indicate  the  type  of  data  to  be 
returned.  This  version  of  the  software  will  recognize  DTED  Levels  0, 1,  and  2  for  retrieval  of  the 
DTED  product.  Application  data  can  be  retrieved  by  setting  the  data  type  parameter  equal  to 
the  name  used  to  register  the  application  data  type. 

The  application  will  also  indicate  whether  the  data  is  to  be  returned  in  a  native  format,  "as  is," 
or  in  a  tailored  format.  If  the  user  specifies  a  tailored  format,  the  user  will  also  provide  a  frame 
size;  whether  the  data  should  be  returned  on  row  major  or  column  major  order,  whether  the 
origin  of  the  data  returned  should  be  the  lower  left  or  upper  left;  and  an  elevation  interval 
(resolution)  of  the  data  to  be  returned.  The  data  is  returned  to  the  requester  a  frame  (a  file)  at  a 
time.  A  count  argument  has  been  provided  with  this  request  to  indicate  the  number  of  frames 
(files)  remaining  upon  receiving  a  frame. 

4.5  Import  of  Application  Data 

The  SDBM  Extensions  effort  provides  the  capability  within  the  SDBM  to  import  application 
defined  data.  Application  data  can  take  any  form.  Examples  include  analysis  results,  spatial 
data  base  map  layers,  a  JMTK  map  display  state  used  to  recreate  a  particular  display, 
perspective  scene  parameters,  etc. 

Each  application  data  type  must  be  registered  with  the  SDBM  prior  to  the  import  process 
taking  place.  This  can  be  accomplished  through  the  SDBM  API  function  JMS_DbService,  thus 
providing  a  means  for  that  data  type  to  be  recognized  by  the  import  process  of  SDBM.  A  Data 
Dictionary  will  be  maintained  for  each  registered  application  defined  data  type.  Metadata 
fields  can  be  added  to  the  application  data's  data  dictionary  through  the  JMS_DDService  API. 
At  import,  the  application  defined  data  will  be  stored  as  a  single  file  into  a  data  base  identified 
in  the  import  process  argument  list  under  a  directory  having  the  same  name  as  the  registered 
data  type. 
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Section  5  Summary 


5.1  Results 

The  initial  task  of  the  SDBM  Extensions  effort  consisted  of  an  in-depth  review  and  analysis  of 
the  functional  requirements  document  for  JMTK,  dated  20  July  1995.  Sterling  Software  med  ^e 
results  of  this  analysis'to  develop  the  SDBM  Software  Requirements  Specification  for  the  GCCS 
Spatial  Data  Base  Module  Extensions  document,  dated  23  August  1996.  The  requiremaite 
identified  within  this  document,  along  with  direction  from  NIMA,  guided  the  implementation 
process  for  the  SDBM  Extensions  effort. 

Subsequent  tasking  included  enhancements  to  the  SDBM  software  to  develop  a  cUent-^rver 
architecture  for  the  SDBM  software,  while  not  preventing  the  software  from  ruraung  within  a 
stand-alone  application.  An  indexing  capability  was  also  provided  to  support  the  retrieval  of 
the  native  geospatial  data  in  a  timely  fashion.  Enhancements  to  the  retrieval  process  were  made 
to  support* the  retrieval  of  application  defined  data  and  the  retrieval  of  a  tailored  geospatia 
LuTs^  LenV  processing  tasks  within  the  SDBM  were  modified  to  perform  asynchronously 
so  as  tocontSue  processing  within  an  SDBM  application  while  a  particular  as>mchronous  task 
is  completing.  In  support  of  the  asynchronous  processmg,  a  transaction  service  was 
LpLLted  to  provide  a  means  by  which  to  query  the  status  of  a  parhcular  asynchronous 

task. 

In  support  of  these  modifications  to  SDBM,  updates  were  made  to  the  SDBMAPI.  These 
modifications  were  described  in  the  SDBM  API  documentation  and  provided  to  NIMA  as  part 
of  the  SDBM  Extensions  effort.  Enhancements  were  made  to  the  Spatial  Date 
and  the  ApiTester  applications  as  well.  Both  appfications  w^e  t0  mcoIPorate  ** 

new  SDBM  functionality  and  the  modifications  made  to  the  SDBM  A1  i. 

5.2  Conclusions 

The  accomplishments  achieved  during  this  effort  provide  insight  into  the  development  of 
modular  geospatial  data  access  capabilities.  Past  implementations  have  often  resulted  m 
systems  where  it  is  difficult  to  upgrade  functionality  without  a  major  software  overhatd.  The 
SDBM  demonstrates  that  it  is  feasible  to  create  modular  software  that  can  interface  application 
programs  with  the  diverse  array  of  geospatial  information  m  a  straight  foreword  manner.  The 
complexity  of  accessing  and  retrieving  data  can  be  hidden  from  the  applications  offering 
developers  a  simple  API  to  work  with. 

A  general  architectural  goal  of  the  JMTK  is  "plug-and-play"  components  TheSDBMwas 
consequently  designed  to  be  a  stand-alone  module  within  JMTK.  The  lack  of  function  calls  to 
any  other  JMTK  x^dule  enables  the  SDBM  to  be  a  true  "plug-and-play  capabihty.  In  addition 
^analysis  of  geospatial  requirements  produced  an  API  that  is  relatively  smdl  ^e  but  has 
been  deLed  to  support  all  stated  JMTK  spatial  access  requirements.  Thus  the  SDBM  can  be 
upgraded  as  required  without  impact  to  other  JMTK  modules  and/or  mission  applications  that 
make  calls  to  it  directly.  Furthermore,  this  "plug-and-play"  capability  has  been  implemented  in 
such  a  way  as  to  support  both  tool  kit  implementation  and/or  a  client/server  environmen  s. 

Performance  has  always  been  a  consideration  and  is  of  paramount  importance^  regarding  the 
access  of  geospatial  information.  Methods  for  organizing,  accessmg,  and  retneving  individual 
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elements  and  tailored  data  products  were  researched.  The  chosen  indexing  method  that  was 
integrated  within  the  SDBM  was  applied  to  the  retrieval  of  elevation  data.  The  improved 
performance  in  DTED  retrieval  over  the  previous  SDBM  release  demonstrates  that  indexing  will 
continue  to  be  an  integral  component  of  spatial  data  base  management. 

In  conclusion,  we  have  learned  from  this  effort  that  modular  software  for  geospatial  data  access 
and  retrieval  is  possible  to  build.  The  plug  and  play  approach  is  a  viable  architecture  for  the 
JMTK  and  will  support  NIMA's  long  range  goals  of  providing  MCG&I  capability  through  COTS 
solutions.  Furthermore,  as  the  SDBM  evolves  to  provide  capabilities  to  more  complex  data  sets, 
such  as  VPF,  the  indexing  capability  will  be  critical  element  in  the  overall  performance. 

5.3  Recommendations 

As  this  contract  demonstrated,  enhancements  are  necessary  to  continue  to  evolve  any  system. 
Several  recommendations  have  been  made  for  enhancing  the  GCCS  SDBM  data  access 
functionality  and  the  overall  design  and  development  of  the  system.  The  following  specific 
recommendations  have  been  noted  to  take  the  SDBM  to  the  next  step  and  to  expand  upon  the 
enhancements  made  during  this  effort: 

1.  Incorporate  additional  data  types  into  the  import  and  retrieval  processes. 

2.  Provide  an  indexing  scheme  to  support  the  data  retrieval  of  RPF,  VPF,  SLF  and  other  data 
types. 

3.  Expand  the  Spatial  Data  Base  Manager  application  to  provide  a  useful  tool  to  the  Spatial 
Data  Base  user/administrator. 

4.  Enhance  the  SDBM  software  so  that  it  is  compatible  with  Windows  NT. 

5.  Ensure  that  follow-on  contracts  make  allowances  for  some  on-site  integration  support  time. 
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5.4.1  Government  Documents 
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Software  Requirements  for  the  GCCS  Spatial  Data  Base  Module  Extensions,  Sterling  Software/ITD, 
23  August  1996. 

Software  Programmer's  Manual  for  the  Joint  Mapping  Toolkit/Spatial  Data  Base  Module,  Sterling 
Software/ITD,  15  September  1997. 

Software  User's  Manual  for  the  Joint  Mapping  Toolkit/Spatial  Data  Base  Module,  Sterling 
Software/ITD,  15  September  1997. 

Software  Test  Plan  for  the  Joint  Mapping  Toolkit/Spatial  Data  Base  Module,  Sterling  Software/ITD, 
15  September  1997. 
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Software  Test  Description  for  the  Joint  Mapping  Toolkit/Spatial  Data  Base  Module,  Sterling 
Software/UD,  15  September  1997. 

CM  Plan  for  the  GCCS  Spatial  Data  Base  Module,  Sterling  Software /ITD,  8  August  1996. 

Software  Engineering  Standards  for  the  GCCS  Joint  Mapping  Toolkit,  Joint  Mapping  Toolkit 
Working  Group,  14  November  1995. 
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Appendix  A  SDBM  Test  Analysis 


A.l  Identification 

This  appendix  summarizes  and  evaluates  the  results  of  testing  the  Spatial  Data  Base  Module 
(SDBM)  Computer  Software  Configuration  Item  (CSCI)  of  the  Joint  Mapping  Toolkit  (JMTK)  for 
the  SDBM  Extensions  effort. 

A.  2  Test  Overview 

The  demonstration  of  the  functionality  of  the  JMTK  SDBM  CSCI  version  3.2  was  conducted  at 
Sterling  Software/ITD,  Beeches  Technical  Campus,  Route  26N,  Rome,  New  York.  The  execution 
of  the  Formal  Qualification  Tests  (FQT)  was  held  on  August  7, 1997,  witnessed  by  an  Air  Force 
representative  of  Rome  Laboratory.  The  hardware  and  software  configuration  used  during  the 
FQT  is  detailed  below. 

The  FQTs  consist  of: 

1.  SDBM  Initialization 

2.  Connection  Services 

a)  Connect  to  a  data  base 

b)  Set  connection  preferences 

c)  Get  connection  preferences 

d)  Disconnect 

3.  SDBM  Data  Import 

a)  Import  VPF  product  from  CD-ROM 

b)  Import  RPF  product  from  CD-ROM 

c)  Import  DTED  product  from  CD-ROM 

d)  Import  VPF  product  from  disk 

e)  Import  RPF  product  from  disk 

f)  Import  DTED  product  from  disk 

g)  Import  application  defined  data  from  disk 

4.  Query  an  SDBM  data  base 

a)  Query  SDBM  data  base  names 

b)  Query  SDBM  pathnames 

5.  Data  Base  Services 

a)  Create  a  data  base 

b)  Register  a  new  format  type 

6.  SDBM  Data  Retrieval 

a)  Retrieve  native  DTED  data 

b)  Retrieve  application  defined  data 

c)  Retrieve  tailored  DTED  data 

7.  Data  Dictionary  Services 

a)  Retrieve  list  of  data  dictionaries 

b)  Retrieve  list  of  elements  from  a  data  dictionary 

c)  Retrieve  data  dictionary  element 

d)  Add  element  to  user  defined  data  dictionary 

8.  Transaction  Services 

a)  Get  transaction  state 
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b)  Cancel  a  transaction 
9.  Get  a  Description  of  an  Error  Code 

Demonstration  Test  Record 

Hardware  Configuration:  Sun  SP ARC  IPC 

Software  Configuration:  SunOS  version  5.5.1  (Solaris  2.5.1) 

TRITEAL  Corporation  Common  Desktop  Environment  (CDE) 

Motif  1.2.2 
X11R5 

SDBM  version  3.2 

Location:  Sterling  Software 

Information  Technology  Division 
Rome,  New  York 

Testing  Dates:  August  7, 1997 

Attendees:  Lieutenant  Douglas  Beridon,  USAF  Rome  Laboratory 
Captain  William  Hart,  USAF  Rome  Laboratory 
Mr.  Christopher  D.  Williams,  Sterling  Software/ITD 
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Formal  Test  1.  SDBM  Initialization: 


•  SDBM  Initialization  Summary 

The  SDBM  Initialization  test  was  designed  to  demonstrate  SDBM's  capability  to  initialize  an 
SDBM  connection  and  hand  back  a  connection  ID  which  an  SDBM  user  will  use  to  identify  a 
connection  for  all  subsequent  services.  The  table  depicted  in  Figure  A-l  summarizes  the 
results  of  this  test. 

•  SDBM  Initialization  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 


Formal  Test  1 

SDBM  Initialization 

Success 

Failure/Errors 

Remarks 

Initialize  an  SDBM  Data  Base 

X 

None 

None 

Figure  A-1.  SDBM  Initialization  Test  Results 
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Formal  Test  2,  Connection  Services: 


a)  Connect  to  a  Data  Base 

The  Connect  to  a  Data  Base  test  was  designed  to  demonstrate  SDBM's  capability  to  connect 
to  an  existing  data  base  maintained  by  SDBM.  The  table  depicted  in  Figure  A-2  summarizes 
the  results  of  this  test. 

•  Connection  Service;  Connect  to  a  Data  Base  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

b)  Set  Connection  Preferences 

The  Set  Connection  Preferences  test  was  designed  to  demonstrate  SDBM's  capability  to  set 
the  connection  preferences  to  a  currently  existing  data  base  connection.  The  test  consists  of 
setting  die  AOI  and  die  data  base(s)  that  will  be  used  throughout  the  connection.  The  table 
depicted  in  Figure  A-2  summarizes  the  results  of  this  test. 

•  Connection  Service,  Set  Connection  Preferences  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

c)  Get  Connection  Preferences 

The  Get  Connection  Preferences  test  was  designed  to  demonstrate  SDBM's  capability  to 
obtain  the  current  connection  settings  for  a  particular  connection.  The  test  consists  of 
providing  a  connection  ID  and  obtaining  the  current  AOI  and  the  data  base(s)  that  will  be 
used  throughout  the  connection.  The  table  depicted  in  Figure  A-2  summarizes  the  results  of 
this  test. 

•  Connection  Service,  Get  Connection  Preferences  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

d)  Disconnect 

The  Disconnect  test  was  designed  to  demonstrate  SDBM's  capability  to  release  a  current 
connection  to  an  SDBM  data  base.  The  table  depicted  in  Figure  A-2  summarizes  the  results 
of  this  test. 

•  Connection  Service,  Disconnect  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 


Formal  Test  2 

Connection  Services 

Success 

Failure/Errors 

Remarks 

a)  Connect  to  a  Data  Base 

X 

None 

None  1 

b)  Set  Connection  Preferences 

X 

None 

None  | 

c)  Get  Connection  Preferences 

X 

None 

None 

d)  Disconnect 

X 

None 

None 

Figure  A-2.  Connection  Services  Test  Results 
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Formal  Test  3,  SPBM  Data  Import: 

a)  Import  VPF  product  from  CD-ROM 

The  Import  VPF  product  from  CD-ROM  test  was  designed  to  demonstrate  the  SDBM's 
capability  to  import  NIMA  Vector  Product  Format  data  from  a  CD-ROM  into  an  existing 
SDBM  data  base.  The  table  depicted  in  Figure  A-3  summarizes  the  results  of  this  test. 

•  SDBM  Data  Import;  Import  VPF  product  from  CD-ROM  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

b)  Import  RPF  product  from  CD-ROM 

The  Import  RPF  product  from  CD-ROM  test  was  designed  to  demonstrate  the  SDBM's 
capability  to  import  NIMA  Raster  Product  Format  data  from  a  CD-ROM  into  an  existing 
SDBM  data  base.  The  table  depicted  in  Figure  A-3  summarizes  the  results  of  this  test. 

•  SDBM  Data  Import,  Import  RPF  product  from  CD-ROM  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

c)  Import  DTED  product  from  CD-ROM 

The  Import  DTED  product  from  CD-ROM  test  was  designed  to  demonstrate  the  SDBM's 
capability  to  import  NIMA  Digital  Terrain  Elevation  Data  from  a  CD-ROM  into  an  existing 
SDBM  data  base.  The  table  depicted  in  Figure  A-3  summarizes  the  results  of  this  test. 

•  SDBM  Data  Import,  Import  DTED  product  from  CD-ROM  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

d)  Import  VPF  product  from  disk 

The  Import  VPF  product  from  disk  test  was  designed  to  demonstrate  the  SDBM's  capability 
to  import  NIMA  Vector  Product  Format  data  from  a  disk  where  the  data  had  previously 
been  copied  to,  into  an  existing  SDBM  data  base.  The  table  depicted  in  Figure  A-3 
summarizes  the  results  of  this  test. 

•  SDBM  Data  Import,  Import  VPF  product  from  disk  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

e)  Import  RPF  product  from  disk 

The  Import  RPF  product  from  disk  test  was  designed  to  demonstrate  the  SDBM's  capability 
to  import  NIMA  Raster  Product  Format  data  from  a  disk  where  the  data  had  previously 
been  copied  to,  into  an  existing  SDBM  data  base.  The  table  depicted  in  Figure  A-3 
summarizes  the  results  of  this  test. 

•  SDBM  Data  Import,  Import  RPF  product  from  disk  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 
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f)  Import  DTED  product  from  disk 

The  Import  DTED  product  from  disk  test  was  designed  to  demonstrate  the  SDBMs 

fn  imnnrt  NTMA  Digital  Terrain  Elevation  Data  from  a  disk  where  the  data  had 

SDBM  data  base.  The  table  depicted  to  Figure  A-3 

summarizes  the  results  of  this  test. 


•  SDBM  Data  Import,  Import  DTED  product  from  disk  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 


•  SDBM  Data  Import,  Import  Application  defined  data  from  disk  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Sectmn  A.2, 
Test  Overview. 


Formal  Test  3 

SDBM  Data  Import 

Success 

v 

Failure/Errors 

None 

Remarks 

None 

a)  Import  VPF  product  from  CD-ROM 
k\  imnnrt  RPF  nroduct  from  CD-ROM 

A 

X 

None 

None 

c)  Import  DTED  product  from  CD- 
ROM 

X 

None 

None 

r(\  imnnrt  VPF  Droduct  from  disk 

X 

None 

None 

imnnrt  RPF  Droduct  from  disk 

X 

None 

None 

imnnrt  DTED  oroduct  from  disk 

X 

None 

None 

g)  import  Application  defined  data 
from  disk 

X 

None 

None 

Figure  A-3.  SDBM  Data  Import  Test  Results 
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Formal  Test  4,  Query  an  SDBM  Data  Base: 

a)  Query  SDBM  Data  Base  Names 

The  Query  SDBM  Data  Base  Names  test  was  designed  to  demonstrate  the  SDBM's 
capability  to  query  SDBM  for  a  list  of  possible  data  bases.  The  table  depicted  in  Figure  A-4 
summarizes  the  results  of  this  test. 

•  Query  an  SDBM  Data  Base,  Query  SDBM  Data  Base  Names  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

b)  Query  SDBM  Pathnames 

The  Query  SDBM  Pathnames  test  was  designed  to  demonstrate  the  SDBM's  capability  to 
provide  a  list  of  paths  to  available  datasets  matching  input  criteria  from  die  Query  SDBM 
Pathnames  request.  The  table  depicted  in  Figure  A-4  summarizes  the  results  of  this  test. 

•  Query  an  SDBM  Data  Base,  Query  SDBM  Pathnames  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 


Formal  Test  4 

Query  an  SDBM  Data  Base 

Success 

Failure/Errors 

Remarks 

a)  Query  SDBM  Data  Base  names 

X 

None 

None 

b)  Query  SDBM  Pathnames 

X 

None 

None 

Figure  A-4.  Query  an  SDBM  Data  Base  Test  Results 
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Formal  Test  5,  Data  Base  Services: 


a)  Create  a  Data  Base 

The  Create  a  Data  Base  test  was  designed  to  demonstrate  the  SDBM's  capability  to  create  a 
new  SDBM  data  base  within  the  SDBM  environment.  The  table  depicted  in  Figure  A-5 
summarizes  the  results  of  this  test. 

•  Data  Base  Services,  Create  a  Data  Base  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

b)  Register  a  new  format  type 

The  Register  a  new  format  type  test  was  designed  to  demonstrate  the  SDBM's  capability  to 
allow  users  to  register  a  new  data  type  recognized  within  SDBM  and  to  provide  the 
identification  criteria  for  recognition.  The  table  depicted  in  Figure  A-4  summarizes  the  results 
of  this  test. 

•  Data  Base  Services,  Register  a  new  format  type  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 


Formal  Test  5 

Data  Base  Services 

Success 

Failure/Errors 

Remarks 

a)  Create  a  Data  Base 
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None 

None 

b)  Register  a  new  format  type 
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None 

None 

Figure  A-5.  Data  Base  Services  Test  Results 


A -8 


Formal  Test  6,  SPBM  Data  Retrieval: 


a)  Retrieve  Native  DTED  data 

The  Retrieve  Native  DTED  data  test  was  designed  to  demonstrate  the  SDBM's  capability  to 
provide  DTED  data  to  a  requester  in  its  native  format,  based  upon  the  parameters  provided 
in  the  request.  The  table  depicted  in  Figure  A-6  summarizes  the  results  of  this  test. 

•  SDBM  Data  Retrieval,  Retrieve  Native  DTED  data  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

b)  Retrieve  Application  Defined  data 

The  Retrieve  Application  Defined  data  test  was  designed  to  demonstrate  the  SDBM  s 
capability  to  provide  Application  defined  data  to  a  requester  based  upon  the  parameters 
provided  in  the  request.  The  table  depicted  in  Figure  A-6  summarizes  the  results  of  this  test. 

•  SDBM  Data  Retrieval,  Retrieve  Application  Defined  data  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

c)  Retrieve  Tailored  DTED  data 

The  Retrieve  Tailored  DTED  data  test  was  designed  to  demonstrate  the  SDBM's  capability 
to  provide  DTED  data  to  a  requester  in  a  tailored  format,  based  upon  the  specifications 
provided  by  the  requester  (i.e.,  point  of  origin  of  the  data,  resolution  of  the  data,  etc.).  The 
table  depicted  in  Figure  A-6  summarizes  the  results  of  this  test. 

•  SDBM  Data  Retrieval,  Retrieve  Tailored  DTED  data  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 
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a)  Retrieve  native  DTED  data 
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None 

None 

b)  Retrieve  Application  defined  data 

X 

None 
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c)  Retrieve  Tailored  DTED  data 
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None 

None 

Figure  A-6.  SDBM  Data  Retrieval  Test  Results 
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Formal  Test  7,  Data  Dictionary  Services: 


a)  Retrieve  List  of  Data  Dictionaries 

The  Retrieve  List  of  Data  Dictionaries  test  was  designed  to  demonstrate  the  SDBM's 
capability  to  provide  a  list  of  the  Data  Dictionaries  available  within  a  data  base.  The  table 
depicted  in  Figure  A -7  summarizes  the  results  of  this  test. 

•  Data  Dictionary  Services,  Retrieve  List  of  Data  Dictionaries  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

b)  Retrieve  List  of  Elements  from  a  Data  Dictionary 

The  Retrieve  List  of  Elements  from  a  Data  Dictionary  test  was  designed  to  demonstrate  the 
SDBM's  capability  to  provide  a  list  of  elements  defined  in  a  particular  Data  Dictionary.  The 
table  depicted  in  Figure  A-7  summarizes  the  results  of  this  test. 

•  Data  Dictionary  Services,  Retrieve  List  of  Elements  from  a  Data  Dictionary  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

c)  Retrieve  Data  Dictionary  Element 

The  Retrieve  Data  Dictionary  Element  test  was  designed  to  demonstrate  the  SDBM's 
capability  to  provide  a  definition  of  a  particular  Data  Dictionary  Element  given  the  Data 
Dictionary  and  Element  name.  The  table  depicted  in  Figure  A-7  summarizes  the  results  of 
this  test. 

•  Data  Dictionary  Services,  Retrieve  Data  Dictionary  Element  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

d)  Add  Element  to  User  Defined  Data  Dictionary 

The  Add  Element  to  User  Defined  Data  Dictionary  test  was  designed  to  demonstrate  the 
SDBM's  capability  to  add  a  new  element  to  a  particular  Data  Dictionary.  The  table  depicted 
in  Figure  A-7  summarizes  the  results  of  this  test. 

•  Data  Dictionary  Services,  Add  Element  to  User  Defined  Data  Dictionary  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 
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Figure  A-7.  Data  Dictionary  Services  Test  Results 


Formal  Test  8,  Transaction  Services: 


a)  Get  Transaction  State 

The  Get  Transaction  State  test  was  designed  to  demonstrate  the  SDBM's  capability  to 
provide  a  status  to  the  requester  regarding  the  state  of  a  particular  ongoing  task.  The  table 
depicted  in  Figure  A-8  summarizes  the  results  of  this  test. 

•  Transaction  Services,  Get  Transaction  State  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 

b)  Cancel  Transaction 

The  Cancel  Transaction  test  was  designed  to  demonstrate  the  SDBM's  capability  to  allow  an 
SDBM  user  to  cancel  the  processing  of  a  currently  ongoing  task.  The  table  depicted  in  Figure 
A-8  summarizes  the  results  of  this  test. 

•  Transaction  Services,  Cancel  Transaction  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 
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Figure  A-8.  Transaction  Services  Test  Results 
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Formal  Test  9,  Get  a  Description  of  an  Error  Code: 


a)  Get  Error 

The  Get  Error  test  was  designed  to  demonstrate  the  SDBM's  capability  to  provide  a  textual 
description  of  a  particular  error  code.  The  table  depicted  in  Figure  A-9  summarizes  the 
results  of  this  test. 

•  Get  a  Description  of  an  Error  Code,  Get  Error 

The  date,  location,  test  personnel,  and  witnesses  are  listed  at  the  beginning  of  Section  A.2, 
Test  Overview. 


Formal  Test  9 
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Figure  A-9.  Get  a  Description  of  an  Error  Code  Test  Results 
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Appendix  B  Acronyms 


ADRG 

ARC  Digitized  Raster  Graphics 

ADRI 

ARC  Digitized  Raster  Imagery 

AFMSS 

Air  Force  Mission  Support  System 

AOI 

Area-of-Interest 

API 

Application  Programmer  Interface 

C3I 

Command,  Control,  Communications,  and  Intelligence 

C4I 

Command,  Control,  Communications,  Computers,  and 
Intelligence 

CADRG 

Compressed  ARC  Digital  Raster  Graphics 

CD 

Compact  Disk 

CD-ROM 

Compact  Disk-Read  Only  Memory 

CDE 

Common  Desktop  Environment 

CIB 

Controlled  Image  Base 

CM 

Configuration  Management 

CM3C 

Common  Mapping  Interface  Control 

CMS 

Common  Mapping  Standard 

CMTK 

Common  Mapping  Toolkit 

COE 

Common  Operating  Environment 

COTS 

Commercial-Off-The-Shelf 

CSCI 

Computer  Software  Configuration  Item 

DCW 

Digital  Chart  of  the  World 

DFAD 

Digital  Feature  Analysis  Data 

DIS 

Data  Interchange  Services 

DISA 

Defense  Information  Systems  Agency 

DMA 

Defense  Mapping  Agency 

DOD 

Department  of  Defense 

DTED 

Digital  Terrain  Elevation  Data 

EA 

Evolutionary  Acquisition 

ED 

Evolutionary  Development 

ELV 

Elevation 

FGDC 

Federal  Geographic  Data  Committee 

FQT 

Formal  Qualification  Test 

GCCS 

Global  Command  and  Control  System 

GIS 

Geographical  Information  System 
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GOTS 

Government-Off-The-Shelf 

IRRP 

Rome  Laboratory's  Image  Products  Branch 

ITD 

Information  Technology  Division 

ITD 

Interim  Terrain  Data 

JMTK 

Joint  Mapping  Toolkit 

JSWG 

Joint  Services  Working  Group 

MACS 

Mapping  Application  Client  Server 

MC&G 

Mapping,  Charting  and  Geodesy 

MCG&I 

Mapping,  Charting,  Geodesy,  and  Imagery 

NDC 

Normalized  Device  Coordinates 

NITF 

National  Imagery  Transmission  Format 

PDC 

Physical  Device  Coordinates 

R&D 

Research  and  Development 

RL 

Rome  Laboratory 

RPF 

Raster  Product  Format 

SDB 

Spatial  Data  Base 

SDBM 

Spatial  Data  Base  Module 

SDT 

Spatial  Display  Tool 

SOW 

Statement  of  Work 

SRS 

Software  Requirements  Specification 

TBMCS 

Theater  Battle  Management  Core  System 

TEM 

Topographic  Evaluation  Module 

U.S. 

United  States 

USAF 

United  States  Air  Force 

VMAP 

Vector  Smart  Map 

VPF 

Vector  Product  Format 

VSC 

View  Surface  Coordinates 

WWMCCS 

World-Wide  Military  Command  and  Control  System 
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Appendix  C  Glossary 


Application  Programmer's  Interface  (API):  A  paradigm  used  to  provide  the  interfaces  between 
an  application  and  a  software  library  of  functions,  a  toolkit  of  functions,  or  another 
application.  The  API  can  also  refer  to  a  collection  of  functions  providing  the  interface  capability 
to  a  software  library,  a  toolkit  of  functions,  or  another  application. 

Cartographic  Display  Process:  The  method  used  to  draw  a  cartographic  map  feature  (e.g.,  VPF 
data  features)  in  the  CMTK  cartographic  window. 

Common  Mapping  Toolkit  (CMTK):  A  software  library  of  functions  which  provide  the 
capability  to  display,  manipulate,  perform  geospatial  analysis,  and  otherwise  exploit  Common 
Mapping  Standard  (CMS)  data  (preprocessed  from  DMA  standard  data)  as  well  as  other  data 
sources  for  the  United  States  Air  Force. 

Common  Mapping  Standard  (CMS):  A  standardized.  Government-owned  and  DMA- 
validated  cartographic  data  base  structure  used  as  the  CMTK  data  base.  The  data  it 
incorporates  is  imported  from  existing  DMA  data  products  such  as  ADRG,  ADRI,  DCW, 
DFAD,  DTED,  etc.  It  provides  a  common  format  for  the  use  of  these  varying  DMA  data 
products. 

Compressed  ARC  Digitized  Raster  Graphic  (CADRG):  A  general  purpose  product, 
comprising  computer-readable  digital  map  and  chart  images.  It  supports  various  weapons: 
Command,  Control,  Communications,  and  Intelligence  (C3I)  theater  battle  management;  mission 
planning;  and  digital  moving  map  systems.  CADRG  data  is  derived  directly  from  ADRG  and 
other  digital  sources  through  down  sampling,  filtering,  compression,  and  reformatting  to  the  RPF 
Standard.  CADRG  files  may  be  physically  formatted  within  a  NITF  message. 

Controlled  Image  Base  (CIB):  A  dataset  of  orthonormalized  and  rectified  grayscale  images.  A 
CIB  supports  various  weapons,  C3I  theater  battle  management,  mission  planning,  and  digital 
moving  map  systems.  CIB  data  are  derived  and  produced  directly  from  digital  images,  and  are 
compressed  and  reformatted  to  conform  to  the  RPF  Standard. 

Dataset  Metadata:  A  Level  3  metadata  file  within  an  SDBM  Spatial  Data  Base.  It  describes  a 
particular  dataset  found  within  a  data  base. 

Data  Base  Metadata:  The  top  level  (Level  1)  of  metadata  within  an  SDBM  Spatial  Data  Base. 
It  describes  the  contents  of  a  particular  data  base. 

Digital  Chart  of  the  World  (DCW):  A  DMA  product  providing  1:1,000,000  scale  vector 
geographic  data.  DCW  was  developed  as  the  initial  product  implementation  of  a  multinational 
R&D  project  designed  to  develop  a  set  of  vector  product  standards  oriented  toward  the 
Geographical  Information  System  (GIS)  environment.  DCW  data  was  derived  from  Operational 
Navigational  Charts  over  most  of  the  globe  and  Jet  Navigational  Charts  over  Antarctica.  The 
DCW  product  is  the  original  name  for  the  current  VPF  standard  product,  VMAP  Level  0. 

Digital  Terrain  Elevation  Data  (DTED):  A  DMA  product  providing  a  uniform  matrix  of  terrain 
elevation  values  for  the  earth's  surface  at  100  meter  resolution.  The  information  content  is 
approximately  equivalent  to  a  1:250,000  scale  resolution. 

GCCS  Common  Operating  Environment  (COE):  Defines  a  distributed  application 
infrastructure  that  promotes  interoperability  in  a  reliable  and  scalable  environment.  Specifically, 
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a  set  of  integrated  services  that  support  mission  software  application  requirements,  and  a 
corresponding  software  development  methodology  and  environment. 

Geographic  Reference  System  (GEOREF):  A  system  used  for  position  reporting.  It  is  an  area- 
designation  method  used  for  interservice  and  interallied  position  reporting  for  air  defense  and 
strategic  operations.  Positions  are  expressed  in  a  form  suitable  for  reporting  and  plotting  on  any 
map  or  chart  graduated  in  latitude  and  longitude  (with  Greenwich  as  prime  meridian) 
regardless  of  map  projection.  Referred  to  as  GEOREF. 

G-Odesy:  An  application  which  exercises  a  major  portion  of  the  CMTK  API-level  functions.  It 
was  developed  during  the  CMIC  effort  and  is  used  to  provide  developers  with  an  environment 
conducive  to  modifying,  testing,  and  exercising  any  portion  of  the  CMTK  source  code  quickly 
and  easily. 

Global  Command  and  Control  System  (GCCS):  Will  become  the  single  Command,  Control, 
Communications,  Computers,  and  Intelligence  (C4I)  system  to  support  Joint  warfighter.  The 
system  objectives  are  to  replace  the  World-Wide  Military  Command  and  Control  System 
(WWMCCS),  and  to  implement  the  C4I  for  the  Warrior  concept.  The  result  will  be  a  single  view 
of  the  military  C4I  that  improves  the  Joint  warfighter's  ability  to  manage  and  execute 
operations. 

Graphics  Transformation:  The  conversion  of  points  from  one  coordinate  system  to  another 
using  a  transformation  matrix.  Graphics  transformations  include  translation,  scaling,  and 
rotation. 

Joint  Mapping  Toolkit  (JMTK):  A  collection  of  application  programmer  interfaces  (APIs)  that 
enable  support  applications  to  interface  with  Mapping,  Charting,  Geodesy,  and  Imagery 
(MCG&I)  functionality.  This  release  of  JMTK  (version  3.0)  is  comprised  of  three  distinct 
modules  that  interact  with  each  other  through  the  defined  APIs.  The  Visual  Module  provides 
map  presentation  functionality.  The  Analysis  Module  performs  geospatial  computations.  The 
Spatial  Data  Base  Module  provides  the  geospatial  data  management  services. 

National  Imagery  Transmission  Format  (NITF):  A  collection  of  related  standards  and 
specifications  developed  to  provide  a  foundation  for  interoperability  in  the  disseminationof 
imagery  and  imagery-related  products  among  different  computer  systems,  as  defined  in  MIL- 
STD-2500. 

Normalized  Device  Coordinates  (NDC):  A  coordinate  system  used  to  address  pixels  on  a 
computer  graphics  screen.  The  range  of  this  coordinate  system  is  similar  to  physical  device 
coordinates,  except  that  the  largest  dimension  (width  or  height)  is  set  to  1.0.  The  NDC  position 
(0.0,  0.0)  is  in  the  lower  left  comer  of  the  screen.  If  the  width  and  height  are  equal,  then  the 
upper  right  comer  of  the  screen  is  NDC  position  (1.0,  1.0).  If  NDC  coordinates  are  used,  then 
graphics  objects  will  take  up  the  same  proportion  of  all  computer  screens,  regardless  of  the 
actual  PDC  dimensions  of  the  screen. 

Physical  Device  Coordinates  (PDC):  A  standard  coordinate  system  used  to  address  pixels  on 
a  computer  graphics  screen.  The  range  of  this  coordinate  system  is  dependent,  but  m  a  typical 
system  the  PDC  of  the  upper  left  pixel  will  be  (0,  0)  and  the  PDC  of  the  lower  left  pixel  will  be 
(width-1,  height-1),  where  width  is  the  number  of  pixels  across  the  screen  in  the  horizontal 
direction,  and  height  is  the  number  of  pixels  across  the  screen  in  the  vertical  direction.  Some 
systems  may  have  PDC  (0,  0)  in  a  different  comer  and  PDC  (width-1,  height-1)  in  the 
diagonally  opposite  comer. 

Pixel:  A  picture  element.  The  smallest  addressable  area  of  a  computer  screen  or  image  file. 
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Raster  Product  Format  (RPF):  A  standard  data  structure  for  geospatial  data  bases  composed 
of  rectangular  arrays  of  pixel  values  (e.g.,  digitized  maps  or  images)  in  compressed  or 
uncompressed  form.  RPF  is  intended  to  enable  application  software  to  use  the  data  in  the 
original  format  on  computer-readable  interchange  media  directly  without  further  manipulations 
or  transformations. 

Rotation:  A  graphics  transformation  in  which  a  coordinate  system  is  rotated  about  its  origin  by 
a  fixed  angular  value. 

Scaling:  A  graphics  transformation  in  which  a  coordinate  system  is  resized  into  a  larger  or 
smaller  coordinate  system  with  possibly  a  different  aspect  ratio. 

Spatial  Data  Base  Module  (SDBM):  The  module  within  the  Joint  Mapping  Toolkit  representing 
all  activities  dealing  with  data  handling.  Those  areas  include  spatial  data  import,  spatial  data 
management,  spatial  data  manipulation,  spatial  data  base  services,  and  spatial  data  export. 

Spatial  Display  Tool  (Sdt):  An  application  developed  to  provide  a  single  comprehensive, 
digital  multisource  MCG&I  information  handling  capability. 

Thread  Tracker:  A  utility  developed  during  the  development  of  JMTK  3.0.  It  provides  the 
capability  to  track  the  functional  hierarchy,  or  functional  threads,  within  a  toolkit  of  functions 
during  execution  time.  It  can  be  turned  off  and  on  as  needed. 

Transformation  Matrix:  A  3x3  matrix  to  be  multiplied  by  a  point  (stored  as  a  vector)  to 
produce  a  corresponding  point  (vector)  in  a  different  coordinate  system.  A  3x3  matrix  will 
transform  a  two  dimensional  point.  A  transformation  matrix  can  be  as  simple  as  an  identity 
matrix,  in  which  case  the  output  is  identical  to  the  input,  or  any  combination  of  translation, 
scaling,  and  rotation  matrices. 

Translation:  A  graphics  transformation  in  which  a  coordinate  system  is  moved  vertically 
and/or  horizontally. 

Vector  Product  Format  (VPF):  The  DMA's  standard  format  for  vector  data.  A  general  user- 
oriented  data  format  for  representing  large  spatially  referenced  data  bases.  VPF  is  designed  to 
be  used  directly  where  software  can  access  the  data  without  time  consuming  conversion 
processing.  VPF  is  also  designed  to  be  compatible  with  a  wide  variety  of  users,  applications, 
and  products. 

Vector  Smart  Map  (VMAP)  Level  0:  The  low  resolution  component  of  DMA's  VMAP  family 
of  products.  Known  as  VMAP  Level  0,  it  is  a  comprehensive  1:1,000, 000-scale  vector  basemap 
of  the  world.  It  consists  of  geographic,  attribute,  and  textual  data  stored  on  CD-ROMs.  To 
show  product  lineage,  it  is  dual  named  VMAP  Level  0  as  well  as  Digital  Chart  of  the  World 
(DCW).  The  name  VMAP  Level  0  will  be  the  only  name  to  continue  beyond  the  initial  release  of 
the  Vector  Smart  Map  Level  0  data. 

View  Surface  Coordinates  (VSC):  A  coordinate  system  used  to  address  pixels  on  a  computer 
screen.  The  range  of  this  coordinate  system  is  the  same  as  that  of  PDC,  but  on  all  systems  the 
VSC  of  the  lower  left  pixel  will  be  (0,  0),  and  the  VSC  of  the  upper  right  pixel  will  be  (width-1, 
height-1).  VSC  should  be  used  in  place  of  PDC  wherever  possible  to  allow  for  system 
portability. 

Volume  Metadata:  A  Level  2  metadata  file  within  an  SDBM  Spatial  Data  Base.  It  describes 
the  data  types  (i.e.,  DCW,  CADRG,  DTED)  found  within  a  data  base  and  the  datasets  present 
for  a  data  type. 
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MISSION 

OF 

AFRL/INFORMATION DIRECTORATE  (IF) 


The  advancement  and  application  of  information  systems  science  and 
technology  for  aerospace  command  and  control  and  its  transition  to  air, 
space,  and  ground  systems  to  meet  customer  needs  in  the  areas  of  Global 
Awareness,  Dynamic  Planning  and  Execution,  and  Global  Information 
Exchange  is  the  focus  of  this  AFRL  organization.  The  directorate’s  areas 
of  investigation  include  a  broad  spectrum  of  information  and  fusion, 
communication,  collaborative  environment  and  modeling  and  simulation, 
defensive  information  warfare,  and  intelligent  information  systems 


technologies. 


